home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-cat-ftpsec-02.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
38KB
|
929 lines
Network Working Group Internet Engineering Task Force
Internet-Draft Common Authentication Technology Working Group
Updates: RFC 959 S. J. Lunt
Bellcore
July 1993
FTP Security Extensions
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Distribution of this memo is unlimited. Please send comments to the
<ftp-wg@tgv.com> mailing list.
1. Description
This document defines extensions to the FTP specification RFC 959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong
authentication, integrity, and confidentiality on both the control
and data channels with the introduction of new optional commands,
replies, and file transfer encodings.
The following new optional commands are introduced in this
specification:
AUTH (Authentication Type), ADAT (Authentication Data), MIC
(Integrity Protected Command), ENC (Privacy Protected Command),
and PROT (Data Channel Protection Level).
A new class of reply types (6yz) is also introduced for protected
replies.
Expires: January 31, 1994 [Page 1]
Internet-Draft FTP Security Extensions July 1993
None of the above commands are required to be implemented, but each
is dependent on the other (except ENC, which is optional).
Note that this specification is compatible with RFC 959.
2. Motivation
The File Transfer Protocol (FTP) currently defined in RFC 959 and in
place on the Internet uses usernames and passwords passed in
cleartext to authenticate clients to servers (via the USER and PASS
commands). Except for services such as 'anonymous' FTP archives,
this represents a security risk whereby passwords can be stolen
through monitoring of local and wide-area networks. This either aids
potential attackers through password exposure and/or limits
accessibility of files to remote users who can or will not accept the
inherent security risk.
Aside from the problem of authenticating users in a secure manner,
there is also the problem of protecting sensitive data and/or
verifying its integrity. An attacker may be able to access valuable
or sensitive data merely by monitoring a network, or through active
means may be able to delete or modify the data being transferred so
as to corrupt its integrity. An active attacker may also initiate
spurious file transfers to and from a site of the attacker's choice,
and may invoke other commands on the server. FTP does not currently
have any provision for the encryption or verification of the
authenticity of commands, replies, or transferred data. Note that
these security services have value even to anonymous file access.
Current practice for sending files securely is generally either:
1. via FTP of files pre-encrypted under keys which are manually
distributed,
2. via electronic mail containing an encoding of a file encrypted
under keys which are manually distributed,
3. via a PEM message, or
4. via the rcp command enhanced to use Kerberos.
None of these means could be considered even a de facto standard, and
none are truly interactive. A need exists to securely transfer files
using FTP in a secure manner which is supported within the FTP
protocol in a consistent manner and which takes advantage of existing
security infrastructure and technology. Extensions are necessary to
the FTP specification if these security services are to be introduced
into the protocol in an interoperable way.
Expires: January 31, 1994 [Page 2]
Internet-Draft FTP Security Extensions July 1993
Although the FTP control connection follows the Telnet protocol, and
Telnet has defined an authentication and encryption option [5], RFC
1123 [4] explicitly forbids the use of Telnet option negotiation over
the control connection (other than Synch and IP). Also, the Telnet
authentication and encryption option does not provide for integrity
protection only (without confidentiality), and does not address the
protection of the data channel.
3. New FTP Commands
The following commands are optional, but dependent on each other.
They are extensions to the FTP Access Control Commands.
AUTHENTICATION TYPE (AUTH)
The argument field is a Telnet string identifying a supported
authentication mechanism. The command represents a request to
perform an authentication protocol exchange based on an
authentication mechanism identified by the argument. Currently,
only KERBEROS_V4 and GSSAPI are defined.
If the server accepts an authentication type with reply code 334,
then the client must next initiate an authentication exchange (via
the ADAT command) based on that authentication type. The goal of
the authentication exchange is to strongly authenticate the user
to the server, and to establish a security context [3] under which
protection of the control and data channels may be performed.
If the server replies with a 234 code, then the authentication
type is accepted, and no ADAT commands are required. This is
useful to indicate to the server that the password to be sent in a
subsequent PASS command is to be interpreted differently than
normal, as in the case of smart cards or other non-disclosing
password systems. Challenge information intended for human
interpretation may be contained in the reply. Such information
may also be conveyed in the text of the reply to the USER command.
If the server rejects a type (reply code 504), or any ADAT command
fails, then the client may try another authentication type by
issuing another AUTH command, or may continue by sending USER and
PASS commands. Thus, the client should request authentication
types in decreasing order of preference (i.e., strength). The
server will reject (with a 503 reply code) any AUTH or ADAT
commands sent after an authentication protocol successfully
completes.
The client should not require the server to support the AUTH
command or any particular authentication type. If either the
server does not support the AUTH command (reply code 500), or the
client and server cannot agree on an authentication type, or no
Expires: January 31, 1994 [Page 3]
Internet-Draft FTP Security Extensions July 1993
authentication exchange succeeds, then the default USER and PASS
commands must be performed.
The AUTH command will normally be the first command transmitted by
the user after the control connections are made, generally before
the USER command. However, some authentication protocols may
require prior knowledge of the remote user name (e.g., some
challenge/response systems). In this case, the USER command may
be sent in advance of the AUTH command.
Some servers will require that authentication be performed before
certain commands (including USER) will be accepted. In this case,
a 530 reply will be sent indicating that an authentication
exchange is required.
AUTHENTICATION DATA (ADAT)
The argument field is a Telnet string representing a base 64
encoded authentication data (see Section 5, "Base 64 Encoding").
The data is specific to the authentication protocol specified by a
previous AUTH command. The ADAT command, and the associated
replies, allow the client and server to conduct an arbitrary
authentication protocol. The client will send authentication data
to the server via the ADAT command, and the server will send
authentication back to the client by including "ADAT=string" in
the reply, where string is also a Telnet string representing base
64 encoded authentication data. The server will reply 501 if the
string could not be base 64 decoded.
If the server sends a 535 reply, then the authentication data
could not be successfully processed, and the client has not been
authenticated. The client may either try another authentication
type by sending another AUTH command, or may send USER and PASS
commands. The server will reply 503 if no AUTH command was
previously accepted.
If the server sends a 335 reply, then the authentication data was
successfully processed, but more authentication data is necessary
to complete the authentication process. In this case, the server
must include encoded authentication data in the reply. The client
must process this returned data and then issue another ADAT
command.
If the server sends a 235 reply, optionally including encoded
authentication data, then the server considers the client
authenticated. The client must process any authentication data
present in the reply.
Appendix I defines the actual protocol for KERBEROS_V4. Appendix
Expires: January 31, 1994 [Page 4]
Internet-Draft FTP Security Extensions July 1993
II defines the actual protocol for GSSAPI.
If an authentication exchange succeeds, then the client's identity
has been authenticated but not yet authorized. The client must
next invoke the USER command to identify to the server the account
(file system) for which access is requested. If the USER command
results in a 231 reply, then the client is authorized, and no
password is required. However, the client must then send the PASS
command to actually log the user in (the actual password is
ignored and should be a dummy value). If the USER command results
in a 333 reply, then the user was not authorized without a
password, and a password must be sent with the PASS command. In
this case, it is recommended that the PASS command be ENC
protected. Additional USER or PASS commands may be sent after
success of an ADAT command.
Once the client is successfully authenticated via AUTH and ADAT
commands, the rest of the data over the control channel (commands
and replies) must be protected, either with integrity (by a
cryptographic checksum) via the MIC command, or with
confidentiality (by encryption) via the ENC command. (Also see
Section 4 on protected replies.) These two commands may be
arbitrarily intermixed. It is up to the client to decide which of
MIC and ENC commands to use, and it is up to the server when to
accept either. The server will return a 502 reply to any other
command. The server will return a 500 reply to a MIC or ENC
command if no ADAT command succeeded.
Commands sent via the Telnet out-of-band signal must also be
protected. That is, if the client sends the Telnet "Interrupt
Process" (IP) signal followed by the Telnet "Synch" signal, then
the command sent to the server immediately afterwards must also
protected.
A requirement of all specifications for authentication exchanges
based on new authentication types is that they convey to the
caller whether encryption is supported on the resultant security
context, since it is not a requirement that the ENC command, 632
protected replies, or the Private protection level be supported.
It is also strongly suggested that per message protection services
supported by each mechanism perform message replay and out-of-
sequence detection, since no provision for these services is
explicitly made within this specification.
Since no explicit provision is made in this specification for the
negotiation of alternate mechanisms for performing per message
protection services, implementors should instead utilize the token
exchange for this purpose.
Expires: January 31, 1994 [Page 5]
Internet-Draft FTP Security Extensions July 1993
INTEGRITY PROTECTED COMMAND (MIC)
The argument field is a Telnet string consisting of a base 64
encoded "safe" message produced by an authentication mechanism
specific message integrity procedure. The server will decode the
received string, verify its integrity via the authentication
mechanism specific message integrity procedure, and upon success,
interpret the resultant string as an FTP command. The user-
process need not include the Telnet end-of-line code within the
encoded command.
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any MIC command which fails
checksum, replay, sequencing, or other applicable security checks.
The server may return a 402 reply to a MIC command if it is not
willing to accept MIC commands and instead will accept ENC
commands only. In this case, the client should retry the enclosed
command under ENC protection.
The three replies defined above must themselves be protected.
There are no other direct replies from MIC or ENC commands; the
resultant FTP command will generate its own replies.
In environments where the native character set is not ASCII, the
client must translate the encapsulated command to ASCII before
passing it to the protection routine, and the server must
translate the encapsulated command from ASCII after passing the
token to the protection routine.
PRIVACY PROTECTED COMMAND (ENC)
The argument field is a Telnet string consisting of a base 64
encoded "private" message produced by an authentication mechanism
specific message confidentiality procedure. The server will
decode the received string, verify its integrity and
confidentiality via the authentication mechanism specific message
confidentiality procedure, and upon success, interpret the
resultant string as an FTP command.
It is strongly recommended that PASS commands be sent under ENC
protection, when possible.
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
Expires: January 31, 1994 [Page 6]
Internet-Draft FTP Security Extensions July 1993
The server will return a 535 reply to any ENC command which cannot
be properly decrypted, or fails checksum, replay, sequencing, or
other applicable security checks.
The server will return a 402 reply if it does not support the ENC
command. In this case, the client should retry the enclosed
command under MIC protection.
The three replies defined above must themselves be protected.
DATA CHANNEL PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying the data
channel protection level. The PROT command will be rejected and
the server will reply 504 if no previous ADAT command succeeded,
or the specified protection level is not supported. Upon success,
a 200 reply will be sent by the server, indicating that the new
protection level is now in effect.
The following codes are assigned for protection levels:
C - Clear
S - Safe
P - Private
The default protection level is Clear. The Safe protection level
is required to be implemented by all authentication types which
exchange ADAT commands, but the Private protection level is
optional.
When using the Safe protection level, all data sent over the data
channel is to be integrity protected by cryptographic checksum.
When using the Private protection level, all data sent over the
data channel is to be privacy protected by encryption.
The sender will apply protection services after all data
transformations associated with the current representation type,
file structure, and transfer mode have been performed. The data
sent over the data channel is, for the purposes of data
protection, to be treated as a byte stream. An authentication
mechanism specific data protection procedure will be employed by
the sender to protect this byte stream. The procedure should
process a buffer of bytes at a time, and send the result as a
stream of bytes, prepending each transferred buffer with a two
byte length field (most significant byte first). Thus, a minimal
implementation must be able to handle a buffer length of 65,536
bytes. (Implementors must ensure that they encrypt a maximum
cleartext buffer somewhat smaller than this such that the
resultant ciphertext buffer is assured to be no greater than this
Expires: January 31, 1994 [Page 7]
Internet-Draft FTP Security Extensions July 1993
maximum.) The receiver will read the two byte length field, and
then read that number of bytes of protected data, passing the
buffer to an authentication mechanism specific data protection
procedure. Further buffers will be similarly read and processed
until all bytes are sent. Any transformations associated with the
current representation type, file structure, and transfer mode
would then be performed by the receiver on the resultant data.
When using block transfer mode, the sender's (cleartext) buffer
size is independent of the block size.
Under the Clear protection level (i.e., as currently defined in
RFC 959), and when in stream mode, the sender indicates end of
file by closing the data connection. This is inherently
unreliable, since the receiver cannot determine whether the
connection was closed prematurely. Transferring files under the
Safe or Private protection level allows the sender to convey a
positive indication of end of file by sending a protected buffer
which contains zero bytes of cleartext data. Upon receipt of such
a zero length cleartext buffer, the recipient should close the
data connection (without further reading from the connection) and
consider the file transfer complete. If the connection is closed
before such a buffer is received, then the file transfer should be
aborted, and the user should be alerted. If the server was the
recipient, then it should send a 535 reply in this case.
If any data protection services fail at any time during data
transfer at the server end, the server will send a 535 reply.
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or
APPE command if the current protection level is not at the level
dictated by the server's security requirements for the particular
file transfer.
4. New FTP Replies
All replies after a successful ADAT command must be protected. A new
reply type is introduced for this purpose, indicated by a sixth value
for the first digit of the reply code:
6yz Protected reply
The text of this reply is to be decoded and interpreted as an FTP
reply (if such decoding is successful). If the reply code is 631,
then the text of the reply is integrity protected in the same
manner as MIC commands. If the reply code is 632, then the text
of the reply is privacy protected in the same manner as ENC
commands. The server need not include the Telnet end-of-line code
within the encoded reply. All replies must be protected once an
ADAT command succeeds. The server may send a protected reply only
Expires: January 31, 1994 [Page 8]
Internet-Draft FTP Security Extensions July 1993
if a previous ADAT command succeeded.
The security policy of the server will dictate when 631 or 632
replies are to be used. As a general rule, the server should send
a 631 reply to a MIC command, and a 632 reply to an ENC command.
The server must not send 632 replies if the client does not
support encryption (this should be indicated by the security
context). If, upon context establishment, it is not known whether
the client supports encryption, then the server may send a 632
reply only if client support of encryption has been indicated
implicitly by means of the client issuing an ENC command or a PROT
P command.
Multi-line replies are handled as follows. If the server sends a
protected reply in which the decoded reply has a hyphen ("-")
immediately following the reply code, then the server will send
the rest of the lines of text of the multi-line reply each
protected and base 64 encoded as was the first line, and each
followed by the Telnet end-of-line code. The last line of the
multi-line reply will be that line which when decoded by the
receiver begins with the initial reply code followed by a space.
For consistency with RFC 959 replies, each line of a protected
multi-line replies should begin with either a 631 or 632 code
followed by a hyphen or, on the last line, a space. However, note
that it is the format of the decoded reply, and not the enclosing
protected reply, that indicates a multi-line reply.
The following is an example showing the format of a four line
multi-line reply:
631-<base64string>
631-<base64string>
631-<base64string>
631 <base64string>
If the server for some reason cannot encode the reply, then the
unprotected reply will be sent instead. However, the client
should ignore the reply code of any cleartext reply sent after the
success of an ADAT command, and instead simply display the text of
the reply to the user.
5. Base 64 Encoding
Base 64 encoding is the same as the Printable Encoding described in
Section 4.3.2.4 of [2] and is defined as follows.
Proceeding from left to right, the bit string resulting from the
mechanism specific protection routine is encoded into characters
which are universally representable at all sites, though not
Expires: January 31, 1994 [Page 9]
Internet-Draft FTP Security Extensions July 1993
necessarily with the same bit patterns (e.g., although the character
"E" is represented in an ASCII-based system as hexadecimal 45 and as
hexadecimal C5 in an EBCDIC-based system, the local significance of
the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used, enabling
6 bits to be represented per printable character. (The proposed
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used for
padding within the printable encoding procedure.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right
across a 24-bit input group output from the authentication mechanism
specific message protection procedure, each 6-bit group is used as an
index into an array of 64 printable characters, namely "[A-Z][a-
z][0-9]+/". The character referenced by the index is placed in the
output string. These characters are selected so as to be universally
representable, and the set excludes characters with particular
significance to Telnet (e.g., "<CR>", "<LF>", IAC).
Special processing is performed if fewer than 24 bits are available
in an input group at the end of a message. A full encoding quantum
is always completed at the end of a message. When fewer than 24
input bits are available in an input group, zero bits are added (on
the right) to form an integral number of 6-bit groups. Output
character positions which are not required to represent actual input
data are set to the character "=". Since all canonically encoded
output is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Implementors should keep in mind that the base 64 encodings in ADAT,
MIC, and ENC commands, and in 631 and 632 replies, may be arbitrarily
long. Thus, the entire line must be read before it can be processed.
Several successive reads on the control channel may be necessary. It
is not appropriate to for a server to reject a command containing a
base 64 encoding simply because it is too long (assuming that the
decoding is otherwise well formed in the context in which it was
sent).
Case should not be ignored when reading commands and replies
containing base 64 encodings.
Expires: January 31, 1994 [Page 10]
Internet-Draft FTP Security Extensions July 1993
6. Command Summary
The following is a summary of the commands described above:
AUTH <SP> <auth-type> <CRLF>
ADAT <SP> <base64string> <CRLF>
MIC <SP> <base64string> <CRLF>
ENC <SP> <base64string> <CRLF>
PROT <SP> <protection-level> <CRLF>
The syntax of the above argument fields (using BNF notation where
applicable) is:
<auth-type> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<protection-level> ::= C | S | P
<base64string> ::= <quads> | <quads><terminal>
<quads> ::= <quad> | <quad><quads>
<quad> ::= <base64char><base64char><base64char><base64char>
<base64char> ::= ASCII A through Z
| ASCII a through z
| ASCII 0 through 9
| ASCII +
| ASCII /
<terminal> ::= <base64char><terminal1><pad><pad>
| <base64char><base64char><terminal2><pad>
<terminal1> ::= A | Q | g | w
<terminal2> ::= A | E | I | M | Q | U | Y | c |
g | k | o | s | w | 0 | 4 | 8
<pad> ::= ASCII =
The following lists the various reply codes for each new command:
AUTH
234
334
500, 501, 503, 504, 421
ADAT
235
335
500, 501, 503, 535, 421
MIC
402
500, 501, 535, 421
ENC
402
500, 501, 535, 421
PROT
Expires: January 31, 1994 [Page 11]
Internet-Draft FTP Security Extensions July 1993
200
500, 501, 504, 421, 530
The following are additional reply codes for existing commands (502
is the only reply for all commands except ENC and MIC once an ADAT
command succeeds):
USER
231
333
STOR
534, 535
STOU
534, 535
RETR
534, 535
LIST
534, 535
NLST
534, 535
APPE
534, 535
The following is the syntax for protected replies:
<code> <SP> <base64string> <CRLF>
<code> ::= 631 | 632
Lines of the following form may preceed this in the case of a multi-
line protected reply:
<code> <hyphen> <base64string> <CRLF>
<hyphen> ::= ASCII -
7. References
[1] Reynolds, Joyce, and Postel, Jon, "File Transfer Protocol (FTP)",
RFC 959, ISI, October 1985.
[2] Linn, John, "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[3] Linn, John, "Generic Security Service API (GSSAPI)", Internet
Draft, November 1992.
[4] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
[5] Borman, D., "Telnet Authentication and Encryption Option",
Expires: January 31, 1994 [Page 12]
Internet-Draft FTP Security Extensions July 1993
Internet Draft, Cray Research, Inc, April 1993.
Security Considerations
Third party file transfers cannot be secured using these extensions,
since a security context cannot be established between two servers
using these facilities (no control connection exists between server
over which to pass ADAT tokens). Further work in this area is
deferred.
APPENDIX I: SPECIFICATION UNDER KERBEROS VERSION 4
The authentication type (for the AUTH command) associated with
Kerberos Version 4 is KERBEROS_V4. If the server supports
KERBEROS_V4, it will respond with a 334 reply code indicating that an
ADAT command is expected next.
The client should retrieve a ticket for the Kerberos principal
"ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
of "ftp", an instance equal to the canonical host name of the server
with all letters in lower case (as returned by krb_get_phost(3)), the
server's realm name (as returned by krb_realmofhost(3)), and an
arbitrary checksum. The ticket must then be base 64 encoded and sent
as the argument to an ADAT command.
The server must base 64 decode the argument to the ADAT command and
pass the result to krb_rd_req(3). The server must add one to the
checksum from the authenticator and sign it using krb_mk_safe(3),
then base 64 encode the result. Upon success, the server must reply
to the client with a 235 code and include "ADAT=base64string" in the
text of the reply. Upon failure, the server will reply 535.
Upon receipt of the 235 reply from the server, the client must parse
the text of the reply for the base 64 encoded data, decode it, and
pass the result to krb_rd_safe(3). The client should consider the
server authenticated if the resultant checksum is equal to one plus
the value previously sent.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
Expires: January 31, 1994 [Page 13]
Internet-Draft FTP Security Extensions July 1993
Note that this specification for KERBEROS_V4 contains no provision
for negotiating alternate means for integrity and confidentiality
routines. Note also that the ADAT exchange does not convey whether
the peer supports confidentiality services.
APPENDIX II: SPECIFICATION UNDER THE GSSAPI
The authentication type (for the AUTH command) associated with all
mechanisms employing the GSSAPI is GSSAPI. If the server supports an
authentication mechanism employing the GSSAPI, it will respond with a
334 reply code indicating that an ADAT command is expected next.
The client should begin the authentication exchange by calling
GSS_Init_Sec_Context, passing in NULL for claimant_cred_handle to get
the default credentials for the user (this is to avoid dependencies
on names for particular mechanisms), 0 for input_context_handle
(initially), NULL for mech_type (indicating "use default mechanism
type"), and a targ_name equal to output_name from GSS_Import_Name
called with input_name_type of NULL and input_name_string of
"SERVICE:ftp@hostname" where "hostname" is the fully qualified host
name of the server with all letters in lower case. The output_token
must then be base 64 encoded and sent to the server as the argument
to an ADAT command. If GSS_Init_Sec_Context returns
GSS_CONTINUE_NEEDED, then the client should expect a token to be
returned in the reply to the ADAT command. This token should
subsequently be passed to another call to GSS_Init_Sec_Context. In
this case, if GSS_Init_Sec_Context returns no output_token, then the
reply code from the server for the previous ADAT command should have
been 235. If GSS_Init_Sec_Context returns GSS_COMPLETE, then no
further tokens should be expected from the server, and the client
should consider the server authenticated.
The server must base 64 decode the argument to the ADAT command and
pass the resultant token to GSS_Accept_Sec_Context as input_token,
setting acceptor_cred_handle to NULL (for "use default credentials"),
and 0 for input_context_handle (initially). If an output_token is
returned, it should be base 64 encoded and returned to the client by
including "ADAT=base64string" in the text of the reply. If
GSS_Accept_Sec_Context returns GSS_COMPLETE, the reply code should be
235, and the server should consider the client authenticated. If
GSS_Accept_Sec_Context returns GSS_CONTINUE_NEEDED, the reply code
should be 335. Otherwise, the reply code should be 535, and the text
of the reply should contain a descriptive error message.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
GSS_Safe for the sender
GSS_Verify for the receiver
Expires: January 31, 1994 [Page 14]
Internet-Draft FTP Security Extensions July 1993
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
GSS_Seal for the sender
GSS_Unseal for the receiver
Both the client and server should inspect the value of conf_avail to
determine whether the peer supports confidentiality services.
Author's Address:
Steven J. Lunt
Bellcore
RRC-1L213
444 Hoes Lane
Piscataway, NJ 08854
Phone: (908) 699-4244
EMail: lunt@bellcore.com
Mailing List: ftp-wg@tgv.com
Chair's Address:
The working group can be contacted via the current chair:
Sam Sjogren
TGV, Inc.
603 Mission St.
Santa Cruz, CA 95060
Phone: (408) 427-4366
EMail: sjogren@tgv.com
Author's Notes:
This is implemented and working for Kerberos V4 on SunOS 4.1.2 using
SunOS source for ftp and ftpd, and also the BSD Reno source for ftp
and ftpd.
YET TO BE DONE:
1. Determine a suitably general targ_name for GSSAPI.
2. Implementation using GSSAPI.
3. The client may fail when processing the ADAT data from a 235
reply, in which case the server thinks things are OK, but the
client thinks otherwise. Unclear how to proceed at that point,
Expires: January 31, 1994 [Page 15]
Internet-Draft FTP Security Extensions July 1993
other than to drop the connection.
4. New state diagrams might need to be drawn for how the AUTH,
ADAT, USER, and PASS commands now flow.
5. It would be desirable to make use of the rcmd principal in
Kerberos V4, but there may be some environments where the ftp
server needs to run in a chroot'ed environment. Thus, the ftp
principal was specified. There should be some way to make use
of the rcmd principal if there is no ftp principal at the
server site.
Expires: January 31, 1994 [Page 16]